In order to facilitate the provision of services to user terminals, a mobile network such as a 3G network will often require the establishment of a secure communication channel or “security association” between client terminals (i.e. mobile terminals) and the network-based service nodes which provide the services. The Generic Bootstrapping Architecture (GBA) defined in the 3GPP Technical Specification TS 33.220 provides a mechanism whereby a client terminal (UE) can be authenticated to a Network Authentication Function (NAF) (i.e. an Application Server), and secure session keys obtained for use between the client terminal and the NAF. FIG. 1 illustrates schematically an example of the simple network model for the GBA, as described in 3GPP TS 33.220, which comprises a Bootstrapping Server Function (BSF), a Network Authentication Function (NAF), a Subscriber Locator Function (SLF), a Home Subscriber System (HSS) and the User Equipment (UE).
The GBA architecture provides a mechanism to bootstrap the Authentication and Key Agreement (AKA) for application security from the 3GPP AKA mechanism described in 3GPP TS 33.102. This mechanism allows a UE to be authenticated to a BSF in the home network on the basis of a secret K which is shared between the USIM of the UE and the HSS of the subscriber's home network. The AKA procedure further establishes session keys from which keys are derived that are afterwards applied between the UE and a NAF. When a UE and NAF wish to obtain session keys from the BSF, the NAF sends a transaction identifier to the BSF, the transaction identifier containing an index which the BSF uses to identify the UE and appropriate keys which it forwards to the NAF.
FIG. 2 illustrates an example signalling flow diagram of the bootstrapping mechanism provided by the GBA. The steps performed are as follows:                A1. A UE initiates the key generation process by sending a bootstrapping request containing a user identity (e.g. the IMPI obtained from the IMSI stored on a USIM, or the IMPI stored on an ISIM) to the BSF over the Ub interface. The UE derives the address of the appropriate BSF from the user identity as outlined in 3GPP TS23.003.        A2. In a multiple HSS environment, the BSF may have to obtain the address of the HSS where the subscription of the user is stored by querying the SLF over the Dz interface. To get the HSS identity the BSF sends the Zh request normally destined to the HSS to a pre-configured SLF.        A3. The SLF then determines the HSS identity and sends a response redirecting the BSF towards the HSS identified in the Redirect-Host AVP. Steps A2 and A3 are not required in a single HSS environment.        A4. The BSF then sends authentication request in the form of a Multimedia-Auth-Request (MAR) message to the identified HSS over the Zh interface.        A5. The HSS then sends an authentication response in the form of a Multimedia-Auth-Answer (MAA) message including an Authentication Vector (AV) for the user. Each AV is comprised of a random number (RAND), an expected response (XRES), a cipher key (CK), an integrity key (IK) and an authentication token (AUTN). The BSF may also retrieve the GBA User Security Settings (GUSS) for the subscriber from the HSS. The GUSS can contain the BSF specific information element and the set of all application-specific User Security Settings (USS), such as user-specific key lifetimes and the type of UICC of the user. A USS is an application and subscriber specific parameter set that defines two parts, an authentication part, which contains the list of identities of the user needed for the application (e.g. IMPUs, MSISDN, pseudonyms), and an authorisation part, which contains the user permission flags (e.g. access to application allowed, type of certificates which may be issued).        A6. The BSF forwards the RAND and AUTN to the UE in a 401 Unauthorised response message (without the CK, IK and XRES). In doing so the BSF requests that the UE authenticate itself.        A7. The UICC of the UE checks AUTN using the shared secret K to verify that the challenge is from an authorised network. The UE also calculates CK, IK and RES using the RAND. This will result in session keys IK and CK being known in both the BSF and the UE.        A8. The UE returns the Digest AKA response (RES), to the BSF.        A9. The BSF authenticates the UE by verifying the Digest AKA response, comparing RES with XRES. The BSF also generates key material Ks by concatenating CK and IK, and generates a bootstrapping transaction identifier (B-TID) that binds the user identity to the keying material Ks. The B-TID is generated in the format of a Network Access Identifier (NAI) by taking the base 64 encoded RAND value and combining this encoded value with the BSF server name. For example, the B-TID may take the form:                    base64encode(RAND)@BS F_servers_domain_name                        A10. The BSF sends a 200 OK message, including the B-TID, to the UE to indicate the success of the authentication. In addition, the BSF supplies the lifetime of the key Ks.        A11. The UE also generates the key material Ks by concatenating CK and IK.        A12. Subsequently, the UE starts communication with a NAF over the Ua interface, and establishes that GBA procedures are to be used between them. The UE supplies the B-TID to the NAF to allow the NAF to retrieve the corresponding keys from the BSF.        A13. The UE derives the key Ks_NAF from Ks and the NAF_Id using a Key Derivation Function (KDF). The NAF_Id is the FQDN of the NAF, concatenated with the Ua security protocol identifier.        A14. The NAF sends a request for key material to the BSF over the Zn interface.        
The request includes the B-TID received from the UE and the NAF_Id.                A15. The BSF derives the Ks_NAF from Ks and the NAF_Id using the same Key Derivation Function (KDF). The BSF then supplies Ks_NAF to the NAF.        A16. The NAF stores the Ks_NAF which can then be used to secure communications between the UE and the NAF.        
After the GBA mechanism has been run for the first time, subsequent requests to establish a security association between the UE and the same or a different NAF may use the already established key material Ks, providing that key has not expired. However, this will still require that the UE initiate a request for establishment of a security association by sending its B-TID to the NAF.
3GPP TS 33.220 also defines a network model for the GBA in scenarios in which, instead of a GBA-capable HSS, there is either a HLR or a HSS that does not support the GBA. FIG. 3 illustrates schematically an example of the simple network model for the GBA when either a HLR or a HSS without Zh interface support is deployed. In this case, the BSF supports a Zh′ interface that implements the Mobile Application Part (MAP) SS7 protocol with the GBA-incapable HSS/HLR, and uses the MAP_SEND_AUTHENTICATION_INFO service in order to obtain the AV for the subscriber. MAP_SEND_AUTHENTICATION_INFO request primitives include the subscriber's IMSI, which is composed of the Mobile Country Code (MCC) consisting of three digits that uniquely identify the country of domicile of the mobile subscriber, the Mobile Network Code (MNC) consisting of two or three digits for GSM/UMTS applications that identifies the home PLMN of the mobile subscriber, and the Mobile Subscriber Identification Number (MSIN) identifying the mobile subscriber within a PLMN. The MAP_SEND_AUTHENTICATION_INFO request can therefore be routed to the appropriate HLR/HSS using the information contained in the subscriber's IMSI. However, the IMPI is used in the request sent by the UE to the BSF over the Ub interface. As such, the BSF derives the subscriber's IMSI from the IMPI prior to sending a request to a GBA-incapable HLR/HSS over the Zh′ interface (see 3GPP TS29.109).
In such circumstances, a GBA-incapable HLR/HSS will not support GUSS such that GUSS information is not sent over Zh′ reference point. If GUSS support is required, then this can be achieved, for instance, by storing the GUSS information in a BSF database (which can be internal and/or external to the entity itself), or in any other network database which is deemed as appropriate for a specific deployment.
According to 3GPP TS 33.220, in systems where only GBA-capable HSSs or GBA-incapable HSSs/HLRs are deployed, then a BSF is configured to use either the Zh or Zh′ interface, and not both. However, there could be scenarios during migration, where both GBA-capable HSSs and GBA-incapable HSSs/HLRs are deployed. For example, network operators are likely to apply a step-wise approach to upgrading networks that do not support GBA whereby, in a first step, only a single BSF and one or a few GBA-capable HSSs would be introduced. Subsequently, the rest of HSSs in the network would be upgraded to support GBA. However, any remaining GBA-incapable HSSs/HLRs may remain active throughout this process.
Alternatively, in a network which supports the Zh′ interface, the network operator may upgrade or introduce only one or a few HSSs to support the Zh interface, whilst the remaining HSSs/HLRs are not upgraded or replaced and continue to use the Zh′ interface. Such circumstances are likely to occur as subscriber register/database infrastructures evolve to support new services and types of access. For example, while 2G users may continue to be managed in legacy HLRs, new GBA-capable HSSs may be introduced to support IMS or LTE subscribers.
In these migration scenarios where some but not all of the HLRs/HSSs have been upgraded to support GBA then, without some mechanism for handling this, then GBA will not be available for all subscribers of that network. Depending upon whether the BSF supports the Zh or Zh′ interface, GBA would only be available either for subscribers whose AV is stored within a GBA-capable HSS, or for subscribers whose AV is stored within a GBA-incapable HLR/HSS.
3GPP TS 33.220 suggests that, during migration from HLRs or HSSs without Zh reference point support to HSS with Zh reference point support, the BSF could be configured with the information required to select between HSSs and HLRs for a subscriber, as illustrated in FIG. 4. Furthermore, 3GPP TS 33.220 also states that such a mechanism involving configuration of the BSF will not be standardized. However, this approach has a number of problems. The BSF, which is normally user unaware (i.e. does not permanently store any user data), would be required to store and check configuration information relating to subscribers in order to achieve user identity resolution and to support the GUSS. As such, the network operator would be required to maintain configuration information within yet another network element, leading to increased operating expenditure (OPEX) and capital expenditure (CAPEX). In addition, the BSF would be required to support both the Zh interface (Diameter) and the Zh′ interface (MAP).